1. Field of the Invention
The present invention generally relates to computer aided software engineering (CASE) and, more particularly, to program debugging in an interactive and dynamic environment for computer program building and debugging. The invention allows a programmer to cross-debug programs from an interactive programming environment to target execution environments. These target environments can differ from the programming environment by their computer processor architectures, by their operating systems, by their runtime environments, by their code formats, by their symbolic debugging information formats. In addition, the invention allows a programmer to simultaneously cross-debug programs on more than one target environment using a single debugger.
Debuggers are highly dependent on the details of target execution environments. Debugging services, when they are provided, differ widely in their features; they are highly non-portable in their interface and their semantics. The invention establishes a program framework from which to build a set of services; it also establishes a portable client interface and nonportable client interface extensions. Portable debugging services benefit developers of debuggers by providing a single programming interface and programming model. The portable services benefit software developers using a programming environment by enabling debuggers to target multiple programs on heterogeneous environments simultaneously, and by allowing remote as well as local debugging.
2. Description of the Prior Art
Object oriented programming (OOP) is the preferred environment for building user-friendly, intelligent computer software. Key elements of OOP are data encapsulation, inheritance and polymorphism. These elements may be used to create program frameworks, which define abstractions for software objects that can be reused as common program code, and augmented through customization. While these three key elements are common to OOP languages, most OOP languages implement the three key elements differently.
Examples of OOP languages are Smalltalk and C++. Smalltalk is actually more than a language; it might more accurately be characterized as a programming environment. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. In Smalltalk, a message is sent to an object to evaluate the object itself. Messages perform a task similar to that of function calls in conventional programming languages. The programmer does not need to be concerned with the type of data; rather, the programmer need only be concerned with creating the right order of a message and using the right message. C++ was developed by Bjarne Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of C. The key concept of C++ is class, which is a user-defined type. Classes provide object oriented programming features. C++ modules are compatible with C modules and can be linked freely so that existing C libraries may be used with C++ programs.
The complete process of running a computer program involves translation of the source code written by the programmer to machine executable form, referred to as object code, and then execution of the object code. The process of translation is performed by an interpreter or a compiler. In the case of an interpreter, the translation is made at the time the program is run, whereas in the case of a compiler, the translation is made and stored as object code prior to running the program. That is, in the usual compile and execute system, the two phases of translation and execution are separate, the compilation being done only once. In an interpretive system, such as the Smalltalk interpreter, the two phases are performed in sequence. An interpreter is required for Smalltalk since the nature of that programming environment does not permit designation of specific registers or an address space until an object is implemented.
A compiler translates the information into machine instructions, which are defined by the processor architecture of the machine which will execute the program. The translation process varies based on the compiler program itself, the processor architecture, the target runtime execution environment, compiler options, target operating system, and on programming interfaces which define services or features available in software packages or libraries. These factors can prevent software portability due to incompatibilities including differences in language syntax, compiler features, compiler options, from ambiguities in the computer language definition, from freedom in the compiler's interpretation in the language, in processor memory addressing modes and ranges, in ordering of memory (byte ordering), and a lack of programming interfaces or features on a target machine. Software portability is a goal for programmers who desire that their software execute on a variety of target platforms. Nonportable programming interfaces hinder the porting process.
Once a program has been compiled and linked, it is executed and then debugged. Because logical errors, also known as "bugs," are introduced by programmers, they will want to detect and understand the errors, using a program debugger. After correcting the errors and recompiling, they use the debugger to confirm that those errors have been eliminated. Other uses for the debugger include inspecting executing programs in order to understand their operation, monitoring memory usage, instrumenting and testing programs, verifying the correctness of program translation by the compiler, verifying the correctness of operation of other dependent programs, and verifying the operation of computer hardware.
Debuggers provide the program with information about the execution state of the running program as well as control of it. Program state includes program and data memory; hardware registers; program stacks; and operating system objects such as queues, synchronization objects, and program accounting information. Debuggers control programs with operations to start, stop, suspend, terminate, step over instructions, step into branches, step over statements, step through subroutine calls, stop at breakpoints, and stop at data watchpoints. Source-level, or symbolic debuggers present the state of executing programs at a high-level of abstraction, closely representing the execution of the program as if the source code were native computer operations.
Noninteractive debuggers usually lack the ability to control programs. They often only allow the programmer to inspect the state after a program has terminated. These are generally called "postmortem debuggers."
Interactive debuggers provide the programmer access to the state of programs while they are running. They allow the programmer to interact with the running program and control its execution.
Hardware debuggers are another class of debuggers which are used to check the operation of programs at a primitive level. For instance, they allow a programmer to view the operation of the CPU as it executes each instruction, or to view data in memory with a limited presentation such as a binary or hexadecimal output. These debuggers are not usually useful to programmers using high-level languages such as C++ because the type of data they provide is highly mismatched with the source code a programmer is debugging.
High-level symbolic debuggers attempt to let a programmer view running programs with the same level of abstraction as the original source code. Because the source code is compiled into machine instructions, the running programs are not actually being executed in the CPU itself. Instead, machine code translations execute "as if" the source code were real operations that could be carried out by the CPU. In order to present the programmer with a view of their program that closely matches their own perception of how the program is operating, high-level symbolic debuggers must use symbolic debugging information provided by the compiler which let the debugger, in essence, perform a reverse translation from the machine instructions and binary data, back into the source code.
The symbolic information used to perform this translation exists in the form of maps which allow the debugger to translate addresses of machine instructions back into source code locations, or to translate data on a CPU program stack back into the local variables declared in the source code.
Traditional program debuggers are limited in many aspects. Some debuggers are dedicated to debug programs generated by a particular development environment. Others may be semiportable but may not be able to target more than one environment at a time. Still others can only debug single process programs, and are not truly interactive.
The difficulty for interactive software debuggers is providing a programmer with the ability to inspect and control all aspects of executing and nonexecuting software computer programs. Debuggers extract information from the host computer system. The host computer system often only provides this information in the form of operating system calls, low-level driver subroutines, memory, hardware registers, or through a wide range of services. Unfortunately, because engineering designs are not driven by a unifying debugging design, the services are often developed ad hoc, simply revealing the data in any manner that is convenient, or by defining control interfaces to executing programs that are convenient to the implementor of the operating system services. And although a general hardware design may consist of a CPU, memory, and I/O or peripheral devices, similarity in computer design may end there. Because of the extent of such disparity in design, very few debuggers have been designed with portability in mind.
Some debuggers, such as gdb or dbx, are said to be "portable" in that some common source code is shared among implementations of debuggers that target heterogeneous platforms. This category of program debuggers are limited for several reasons: they are designed to only allow debugging of a single target environment at a time; they do not have necessary features to support interactive debugging through asynchronous user operations; program reuse is limited in that abstractions created for one target environment cannot always be used widely across a wide host of target systems; and they require extensive configuration of the program source code before building.
The Portable Debugging Services approach solves these problems by specifying an architecture for the services, an implementation for the framework expressing the design and protocol of the architecture, and by using extensions to the framework via inheritance and polymorphism, two features of object-oriented programming principles.
The Pi debugger, by Thomas Cargill at AT&T Bell Labs, is implemented using object-oriented techniques, but not for the purposes of developing portable debugging services. Instead, Cargill created a set of programming abstractions which could be used to represent class and data structures of programs. The Pi debugger does not have abstractions to support debugging multiple target environments concurrently.
Program debuggers are often used for local debugging, meaning that the development programming environment running the full debugger is the same host running the target program. Some program debuggers allow remote debugging, but do not use a uniform communication model for both. The Portable Debugging Services approach is to use a unified model of client-server debugger communication. This mechanism does not only work on homogeneous environments, but it also functions transparently on heterogeneous environments.